[% setvar title The Perl 6 Summary for the week ending 20030420 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the week ending 20030420'></a><h1>The Perl 6 Summary for the week ending 20030420</h1>
<p>You know how it is, you go away for a lovely weekend folk festival in
Wales, you have a really good, relaxed time, singing yourself hoarse
and generally forgetting all about technology before coming home to
email from the perl.com editor asking if he could have the summary
about half an hour ago, and then you skim through the lists and find
nearly 300 messages unread? You do? I thought it was just me. So,
having utterly failed (by virtue of being elsewhere) to get a summary
written by Monday, I'm currently shooting for 'getting it
written'. Welcome to this week's Perl 6 summary; all the fun of the
Perl 6 lists with none of the tedious 'reading every message'.</p>
<p>Let's see if I can't ease myself back into the Perl 6 vibe by
summarizing the still rather quiet perl6-internals list first...</p>
<a name='Building Parrot on Win32'></a><h2>Building Parrot on Win32</h2>
<p>Steve Fink has been busy committing (in the CVS rather than the
culpability sense) Mattia Barbon's patches to get Parrot building
happily in a Win32 environment. If you have such an environment, now
would probably be a good time to grab the latest Parrot from CVS and
see if it builds for you. I'm sure the list would be grateful to hear
of your experience, good or bad.</p>
<a name='PMC documentation'></a><h2>PMC documentation</h2>
<p>After seemingly weeks in the wilderness with very little feedback,
Alberto Sim&otilde;es finally got some comments on (and thanks for) his
latest PMC doc patches from Steve Fink and Brent Dax. The docs haven't
made it into the distribution yet though, but it can only be a matter
of time.</p>
<p><a href='http://groups.google.com/groups?threadm=20030414083708.GA1510@alfarrabio.di.uminho.pt' target='_blank'>groups.google.com</a></p>
<a name='Is PMC size fixed?'></a><h2>Is PMC size fixed?</h2>
<p>Mattia Barbon wanted to know if it would eventually become possible to
create PMCs with additional data members. Dan says not; PMCs are
allocated from arenas which apparently means they need to be the same
size (variable sized PMCs would mean adding complexity to the garbage
collector, which is already complicated enough thanks very much...)</p>
<p><a href='http://groups.google.com/groups?threadm=Mahogany-0.64.2-628-20030415-212901.00@rbnet.it' target='_blank'>groups.google.com</a></p>
<a name='Dan Does Design Decisions'></a><h2>Dan Does Design Decisions</h2>
<p>Dan announced a few design decisions:</p>
<ul>
<li><a name='It's time to start assigning permanent opcode numbers to some of the opcodes.'></a>It's time to start assigning permanent opcode numbers to some of the
opcodes.</li>
<li><a name='There's some new stack ops, halfpop[insp].'></a>There's some new stack ops, <code>halfpop[insp]</code>.</li>
<li><a name='We now have can and does ops.'></a>We now have <code>can</code> and <code>does</code> ops.</li>
<li><a name='Dan explained that can and does were there to support fast interface polymorphism.'></a>Dan explained that <code>can</code> and <code>does</code> were there to support fast
interface polymorphism.</li>
</ul>
<p><a href='http://groups.google.com/groups?threadm=a0521060abac206fe31be@' target='_blank'>groups.google.com</a>[63.120.19.221] -- permanent opcode numbers</p>
<p><a href='http://groups.google.com/groups?threadm=a05210609bac203bc6e40@' target='_blank'>groups.google.com</a>[63.120.19.221] -- halfpop</p>
<p><a href='http://groups.google.com/groups?threadm=a0521060bbac22af49f56@' target='_blank'>groups.google.com</a>[63.120.19.221] -- can/does</p>
<p><a href='http://groups.google.com/groups?threadm=a05210609bac4968b906b@' target='_blank'>groups.google.com</a>[63.120.19.221] -- Interfaces/Classes</p>
<a name='Short-lived memory allocation'></a><h2>Short-lived memory allocation</h2>
<p>Luke Palmer wondered what the Right Way was to allocate dynamic memory
that wouldn't be needed beyond a function invocation. The answer, of
course, was 'use Parrot memory management and let Garbage Collection
work its shiny magic'. Toward the end of the thread Dan let on that
Parrots Garbage Collector is 'always going to be walking the system
stack' so there was no need to worry about anchoring the newly
allocated buffer to the root set for the duration of the function
invocation, which seems to be a new commitment. Both Dan and Steve
Fink observed that the memory documentation could use updating to
clarify best practice for everyone. Volunteers?</p>
<p><a href='http://groups.google.com/groups?threadm=ygc65pffcoo.fsf@babylonia.flatirons.org' target='_blank'>groups.google.com</a></p>
<a name='How deep is clone?'></a><h2>How deep is <code>clone</code>?</h2>
<p>Alberto Sim&otilde;es asked how deeply the <code>clone</code> operator
worked. According to Leopold T&ouml;tsch it's a deep, recursive
clone, which he noted makes for interesting times when dealing with
self referencing structures (Dan reckoned that it shouldn't be too bad
if you take advantage of the GC system's graph traversal
smarts...). Luke Palmer wondered why the default was a deep copy as,
he claimed, deep copies were seldom needed. He wondered how to make a
shallow copy. Leo suggested extending clone with an extra parameter to
specify deep or shallow copying. Dan said that it is the way it is
because he said so, and that one would make a shallow copy with
assign.</p>
<p><a href='http://groups.google.com/groups?threadm=20030416112524.GA9757@alfarrabio.di.uminho.pt' target='_blank'>groups.google.com</a></p>
<a name='Shared memory'></a><h2>Shared memory</h2>
<p>David Robins wondered whether Parrot's memory allocation system would
cope with sharing memory between processes and found some messages in
the archive that seemed to imply that 'it will cope eventually'. He
wondered <i>how</i> it would cope. Warnock's Dilemma applies...</p>
<p><a href='http://groups.google.com/groups?threadm=Pine.LNX.4.44.0304170912260.19245-100000@davidrobins.net' target='_blank'>groups.google.com</a></p>
<a name='A New GC approach?'></a><h2>A New GC approach?</h2>
<p>Kurt Stephens announced that he had a partially written 'conservative,
non-copying &quot;treadmill&quot;' GC system that could work in real time
without stopping the world. He wondered if it could be useful for
Parrot. No comments so far...</p>
<p><a href='http://groups.google.com/groups?threadm=3E9F3F20.306@kurtstephens.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://kurtstephens.com/research/index.html' target='_blank'>kurtstephens.com</a></p>
<a name='IMC and variable number of arguments'></a><h2>IMC and variable number of arguments</h2>
<p>K Stol wondered how to handle a variable number of function arguments
in IMC code. Dan remarked that it was covered by the Parrot calling
conventions (presumably IMC code doesn't do the dfull Parrot calling
conventions though). Leo T&ouml;tsch suggested making sure that the
last thing pushed onto the argument stack was the number of arguments,
and Will Coleda suggested passing a single PMC like a PerlArray...</p>
<p><a href='http://groups.google.com/groups?threadm=BAY1-DAV58yhJBbdbuN0000d25d@hotmail.com' target='_blank'>groups.google.com</a></p>
<a name='Meanwhile, over in perl6-language'></a><h1>Meanwhile, over in perl6-language</h1>
<p>If I were asked to summarize this week's traffic on perl6-language with
one word, that word would be 'Types'. It turns out that thinking about
types, and how they should behave in Perl 6, is hard. I don't envy
Damian the writing of the next Exegesis, that's for sure.</p>
<p>Instead of presenting the threads in roughly chronological order this
week I'm going to deal with the none type related threads first and
then attempt to sketch the current issues with types without quite so
much reference to individual threads. Cover me, I'm going in...</p>
<a name='Currying questions'></a><h2>Currying questions</h2>
<p>Last week, Ralph Mellor had asked whether currying assumptions could
be overridden when the curried function was called and Luke Palmer had
said he didn't think so. This week Damian answered with a rather more
authoritative &quot;No, they can't be overridden, just make a call to the
original function.&quot;. Ralph had also wondered if there would be a way
to specify whether currying assumptions were made by binding or by
copying a value (currently, they get bound, just like they do when you
call a function normally (I wonder what happens when the function
prototype specifies <code>is copy</code>)). Damian said that, if you wanted to
make an assumption based on a copy then you needed to explicitly make
that copy.</p>
<p><a href='http://groups.google.com/groups?threadm=3E968850.2000604@self-reference.com' target='_blank'>groups.google.com</a> -- Ralph's original questions</p>
<a name='Are all list constructors iterators?'></a><h2>Are all list constructors iterators?</h2>
<p>'Marek Ph.' admired the shiny goodness that is lazy evaluation and
wondered if <i>all</i> list constructors were actually iterators. He
wanted to know if that meant that</p>
<pre>    @a = 1 .. Inf;
    splice @a, 5, 2;</pre>
<p>would yield</p>
<pre>    @a == (1 .. 4, 7 .. Inf)</pre>
<p>He also asked if the <code>x</code> operator would generate an iterator
too. Luke Palmer thought the answer to both questions was &quot;Yes&quot;.</p>
<p><a href='http://groups.google.com/groups?threadm=200304140800.04087.philipp.marek@bmlv.gv.at' target='_blank'>groups.google.com</a></p>
<a name='... but foo('bar')'></a><h2>... but foo('bar')</h2>
<p>St&eacute;phane Payrard spotted a possible ambiguity in Perl 6's
grammar. He wanted to know if</p>
<pre>    ... but foo('bar')</pre>
<p>set the property 'foo' to the value 'bar', or did it create a property
with the name being the value returned by a function call of
<code>foo('bar')</code>. He wondered what the syntax would be to get the 'other'
meaning. Luke Palmer thought the first part was that the property
'foo' would get set to 'bar' (so do I, unless the thing implementing
the property has some special semantics). He suggested that to force
the call to the function to get a property name one would do one of:</p>
<pre>    ... but $(foo('bar'))</pre>
<p>or</p>
<pre>    ... but &amp;foo.('bar')</pre>
<p>I prefer the second of those two.</p>
<p><a href='http://groups.google.com/groups?threadm=20030414194736.GF2610@stefp.dyndns.org' target='_blank'>groups.google.com</a></p>
<a name='Perl 6 parser questions'></a><h2>Perl 6 parser questions</h2>
<p>Right at the end of last week, Austin Hastings asked a bunch of
questions about the behaviour of the Perl 6 parser. He wondered, for
instance, if, in the future, he'd be able to (usefully) say:</p>
<pre>    #!/usr/bin/perl6.1
    use Perl6::Grammar v6.0.0.2;</pre>
<p>Larry answered this question (&quot;I don't see why not&quot;) and all of
Austin's other questions on this topic. Apparently the Perl 6 Parser
will be documented 'whenever Apocalypse 18 comes out'.</p>
<p><a href='http://groups.google.com/groups?threadm=20030413195322.44208.qmail@web12306.mail.yahoo.com' target='_blank'>groups.google.com</a></p>
<a name='Initializations outside of control flow'></a><h2>Initializations outside of control flow</h2>
<p>Mark J. Reed asked about elegant ways of initializing shared
variables. He wanted something a little neater than the blunderbuss of
a <code>BEGIN</code> block. Larry obliged with one of his 'thinking aloud'
posts which, while not giving us a final answer does give us a few
signposts. It's looking like we'll have traits along the lines of:</p>
<pre>    state $where is begin($value);
    state $where is check($value);
    state $where is  init($value);
    state $where is first($value);</pre>
<p>Where the traits work analogously to <code>BEGIN</code>, <code>CHECK</code>, <code>INIT</code> and
<code>FIRST</code>.</p>
<p><a href='http://groups.google.com/groups?threadm=20030415143435.GD7176@charm.turner.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=20030415181942.GA11245@wall.org' target='_blank'>groups.google.com</a></p>
<a name='The new returns keyword'></a><h2>The new <code>returns</code> keyword</h2>
<p>David Storrs was a little worried about the possible clash between the
new <code>returns</code> keyword -- introduced in Apocalypse 6 -- and
<code>return</code>. Michael Lazzaro pointed out that the 'possible clash' was
almost certainly deliberate, after all:</p>
<pre>    sub foo returns Bar {...}</pre>
<p>reads rather well. David had used the example <code>my $spot returns Dog</code>,
which does look rather ugly, but Michael pointed out, in the case of a
variable declaration, it made more sense to use <code>my $spot of Dog</code> or
even <code>my Dog $spot</code>. Michael commented that this choice of syntax
meant the programmer was able to pick the most readable phrase for a
given situation.</p>
<p><a href='http://groups.google.com/groups?threadm=CCE85CBE-6F72-11D7-A307-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a></p>
<a name='A17 early discussion: Perl 6 threading proposal'></a><h2>A17 early discussion: Perl 6 threading proposal</h2>
<p>Austin Hastings posted what would once have been called an RFC about
Perl 6's threading model. No comments so far.</p>
<p><a href='http://groups.google.com/groups?threadm=20030415182938.6630.qmail@web12306.mail.yahoo.com' target='_blank'>groups.google.com</a></p>
<a name='wrap from Synopsis 6'></a><h2><code>wrap</code> from Synopsis 6</h2>
<p>David Storrs wondered if the new <code>.wrap</code> method, which returns a
unique id identifying the particular 'wrapper' could have an
associated warning if the resulting id wasn't stored somewhere. Adam
D. Lopresto and Austin Hastings weren't keen...</p>
<p><a href='http://groups.google.com/groups?threadm=20030416074404.A72173@megazone.bigpanda.com' target='_blank'>groups.google.com</a></p>
<a name='The difference between - $arg {...}&gt; and sub ($arg) {...}'></a><h2>The difference between <code>-</code> $arg {...}&gt; and <code>sub ($arg) {...}</code></h2>
<p>David Storrs asked for a 'micro-Exegesis' on the difference between
<code>-</code> $foo {...}&gt; and <code>sub ($foo) {...}</code> since they both seemed to
generate anonymous subroutines. There were an awful lot of responses
to this. Essentially the difference is that a 'pointy block' (my
coinage I think) is just a block that has a signature. The main
difference is what happens to a <code>return</code>.</p>
<p>In a block or a pointy block, a <code>return</code> returns from the subroutine
that lexically contains that block, not simply from the block
itself. If you want to leave a block prematurely without returning
from its enclosing subroutine, you would use the <code>leave</code> keyword.</p>
<p>This distinction between a Block and a Sub allows for some rather neat
(Smalltalkish) idioms</p>
<pre>    multi iterate_over_file( String $path: Block &amp;block ) {
        my $fh = open File: '&lt;', $path or
            fail &quot;Couldn't open $path: $!&quot;;
        while &lt;$fh&gt; {
            &amp;block($_);
        }
    }

    sub find_user ($user_name) {
        iterate_over_file &quot;/etc/passwd&quot; -&gt; $line {
            return $line but true if /^$user_name/;
        }
        return undef;
    }</pre>
<p>This is a somewhat contrived example, but I think it's useful as an
illustration. If a Block were exactly the same as a sub, then the
<code>return</code> in <code>find_user</code> would return to the middle of the <code>while</code>
loop in <code>iterate_over_file</code> and <code>iterate_over_file</code> would only
return after it had gone through every line in the password file,
which would mean that <code>find_user</code> would always return undef. However,
a return from inside a block returns from the subroutine <i>containing</i>
the block so <code>find_user</code> behaves as expected and we get to write
powerful control structures without having to resort to macros. I do
wonder if the it would be possible for a function like
<code>iterate_over_file</code> to <code>CATCH</code> the block's Return exception
though...</p>
<p><a href='http://groups.google.com/groups?threadm=20030416074937.B72173@megazone.bigpanda.com' target='_blank'>groups.google.com</a></p>
<a name='Compulsorily named parameters?'></a><h2>Compulsorily named parameters?</h2>
<p>The debate over declaring non optional named parameters continued as
Damian joining in. The current consensus appears to be that the
various optional/named/slurpy shorthands introduced in Apocalypse 6
should stay pretty much as they are, but that it should be possible to
declare more complex parameter requirements using sensibly named
traits. John Siracusa still wants a more 'powerful' shorthand, but
there doesn't seem to be anyone taking his side on that.</p>
<p><a href='http://groups.google.com/groups?threadm=3E99F811.30603@conway.org' target='_blank'>groups.google.com</a></p>
<a name='Multimethod invocants'></a><h2>Multimethod invocants</h2>
<p>Multimethods still appear to be causing some confusion, mostly to do
with how they are called and dispatched, and which method parameters
participate in the dispatch. There's a largish contingent (and I
probably my count myself a member of that contingent, spot the bias)
who would like to be able to write:</p>
<pre>    multi infix:@ (Number $x, Number $y) { new Point: $x, $y }

    class point {
        ...
        multi make_rectangle ( Point $p ) {
            new Rectangle: $_, $p;
        }
        multi make_rectangle ( Number $x, Number $y ) {
            .make_rectangle( $x @ $y );
        }
    }</pre>
<p>Which isn't allowed. Instead you would have to write:</p>
<pre>    multi make_rectangle ( Point $p, Point $q ) {
        new Rectangle: $p, $q;
    }

    multi make_rectangle ( Point $p, Number $x, Number $y ) {
        make_rectangle ($p, $x @ $y);
    }</pre>
<p>And you also have to be wary of</p>
<pre>    my Point $p;

    ...

    $p.make_rectangle($x @ $y);</pre>
<p>which would first try to dispatch to Point's <code>make_rectangle</code>
'unimethod', only attempting to dispatch via a multimethod if there is
no such method. Personally, I think there's room for a spoonful or two
of syntactic sugar to allow for the 'method variant' style of
declaration as well as the full on generic multimethod style (which
would, of course, underpin the more restricted method variant
style). However, if it doesn't exist out of the box I expect someone
(me?) will write a set of macros to make things work.</p>
<p>In the message referenced, Damian explains the current state of the
multimethod art...</p>
<p><a href='http://groups.google.com/groups?threadm=3E99FEA8.2090009@conway.org' target='_blank'>groups.google.com</a></p>
<a name='Types...'></a><h1>Types...</h1>
<p>Well, that's 100 or so messages accounted for. Which leaves another
173 messages remaining all of which concern types. The problem as I
see it is that different people seem to understand different things
from the word type, and there's a lot of people talking at cross
purposes as well as a fair amount of axe grinding going on.</p>
<p>Now, I could just punt and write something like &quot;Everyone except Leon
Brocard talked for ages about types. Here are the links to those
threads&quot; which would at least has the virtue of getting the god awful
running joke out of the way, but that would smack of cheating. So,
what I'm going to do is to only cheat slightly. At the bottom of this
section you'll find links to all the threads that discussed types this
week. However, before that I'll try give you a (biased) overview of
the issues involved and the areas of confusion.</p>
<a name='An illustrative quotation from Lewis Carroll'></a><h2>An illustrative quotation from Lewis Carroll</h2>
<p>&quot;The name of the song is called 'Haddocks' Eyes.'&quot; [said the White
Knight.]</p>
<p>&quot;Oh, that's the name of the song, is it?&quot; Alice said, trying to feel
interested.</p>
<p>&quot;No, you don't understand,&quot; the Knight said, looking a little
vexed. &quot;That's what the name is called. The name really is 'The Aged,
Aged Man.'&quot;</p>
<p>&quot;Then I ought to have said 'That's what the song is called'?&quot; Alice
corrected herself.</p>
<p>&quot;No you oughtn't: that's another thing. The song is called 'Ways and
Means' but that's only what it's <i>called</i>, you know!&quot;</p>
<p>&quot;Well, what is the song then?&quot; said Alice, who was by this time
completely bewildered.</p>
<p>&quot;I was coming to that,&quot; the Knight said. &quot;The song really is
'A-sitting On a Gate': and the tune's my own invention.&quot;</p>
<p>-- From Alice Through The Looking Glass, by Lewis Carroll</p>
<a name='Two types of type'></a><h2>Two types of type</h2>
<p>Perl 6 draws an important distinction between 'variable type' and
'value type'. A variable is a binding between a name and a
container. The variable type is the type of the container associated
with the variable's name. A variable's 'value type' is the expected
type of the value stored in the variable's container. As far as I can
tell, Perl is weirder than the average programming language in this
respect in that it allows the programmer to specify both sorts of
type. In C for instance, a value doesn't know its own type, it's just
an area of memory that is interpreted according to the type of the
variable that it is accessed via (or according to the type it is cast
into). Meanwhile, in lisp like languages, 'variables' are simply keys
in a symbol table, and the values in that symbol table are untyped
pointers to values which know their own type.</p>
<p>Perl 6's symbol tables are rather more like Lisp symbol tables than C's,
with the added wrinkle that the symbol table values are rather more
sophisticated containers than simple generic pointers. This complexity
arises for a couple of reasons:</p>
<ul>
<li><a name='Tied variables.'></a>Tied variables.</li>
<p>Instead of storing a variable's value in one of the
core container types (Array, Hash, Scalar), it can be useful to use a
custom container type to allow for 'magical' behaviour:</p>
<pre>    my $FTSE is ShareIndex('FTSE');
    print &quot;$FTSE&quot;;
    # FTSE 100 Index: 3916.70 (+27.50/+0.7%) at 2003042216:40</pre>
<li><a name='Context'></a>Context</li>
<p>Context is really important to Perl. If you look at an array variable
in a numeric context, then you get the number of items in the array;
in list context, a list of all the items in the array; in a scalar
context, a pointer to the array. This context dependent behaviour is
best handled by the container object, possibly with the assistance of
the contained object, but not always.</p>
</ul>
<p>Scalars turn out to be one of the more remarkable types of Perl
containers. At their simplest they can be thought of as a container
which can hold at most one 'atomic' thing. Perl 5 scalars have
three(?) slots for Number, String and Reference values (On IRC, Dan
tells me that Perl 6 scalars will probably have slots for String,
Float, Integer, Boolean and Reference values). These different 'scalar
value types' can, with certain restrictions be treated without regard
to their 'actual' type: A Number in a string context will give a
sensible string representation, a string in a number context will give
an appropriate numeric value, but not every possible scalar value type
can be sensibly viewed as any other type; if you try and use a number
in a reference context, you're going to get an error for instance. For
added fun, it's perfectly possible for a scalar variable to contain
both a Number value and a String value (In Perl 5, <i><a href='http://search.cpan.org/perldoc?Scalar::Util'>Scalar::Util</a></i>
provides a nice interface to this preexisting capability. On IRC, Dan
suggests that the Perl 6ish way of doing this will probably be <code>my $i
= 4 but &quot;Bibble!&quot;;</code>).</p>
<a name='What are value type declarations for?'></a><h2>What are value type declarations for?</h2>
<p>Some people see value type declarations as being important for
programmer safety. They want to see a situation where:</p>
<pre>    my Number $foo = some_function_returning_a_string();</pre>
<p>or</p>
<pre>    sub a_func (Number $param) { ... }

    a_func(&quot;A string&quot;);</pre>
<p>will throw exceptions, preferably at compile time.</p>
<p>Others want to see those same code fragments coerce any values
assigned to them into the appropriate types (possibly with a
warning) and see value type declarations simply as a way of letting
the compiler do automatic optimization of code (if you have declared
that a given variable will only contain, say, a number, you can (at
least) get rid of a layer of indirection in accessing that value).</p>
<p>Others don't really care one way or the other about whether or not to
coerce, they just want to use value types in setting up multimethods.</p>
<p>Still others don't really like the idea of declaring types at all, but
do see value in ML like type inference for programmer safety
reasons...</p>
<p>Others want to let the programmer choose, and worry about how to
implement something which will let that happen. I'm a 'let the
programmer choose, and the compiler optimize what it can' kind of guy.</p>
<a name='Are types the same as objects?'></a><h2>Are types the same as objects?</h2>
<p>If types are the same as objects, do they all inherit from a common
base class? If they do, what does the hierarchy look like? What about
interfaces? Do they need to be explicitly declared or can they be
inferred. If they can be inferred, what about the problem of:</p>
<pre>    class Tree {
        method feed {...}
        method grow {...}
        method bark {...}
        ...
    }

    interface Canine {
        method feed {...}
        method grow {...}
        method bark {...}
    }

    class Borzoi {
        method feed {...}
        method grow {...}
        method bark {...}
    }

    ...

    multi treat($vet, Canine $critter ) {...}
    
    treat($some_vet, Tree.new); # Should this fail?</pre>
<p>Arrghh!!! Make the hurting stop!</p>
<p>However, I don't care what Dan says, I want every type to have an
associated class, and I want them all to inherit from some sort of
common base class (at least conceptually, and, if I'm prepared to take
the performance hit and jump through the hoops, actually. Sometimes
you need to override Scalar's behaviour (or whatever)) but I don't
think the inheritance trees that have been bandied about so far even
come close to expressing the semantics we need. Expect a longish post
to Perl 6 language on this at some point. Probably with (more or less)
pseudo code.</p>
<a name='Another distinction to think about'></a><h2>Another distinction to think about</h2>
<p>OO theory talks about value objects and reference objects. (I'm using
'object' here to try and get come conceptual distance from 'value
type'). Here's an abstract example of what I mean</p>
<pre>    my $a = new ValueObject: value =&gt; 10;
    my $b = $a;

    $b.set_value(20);
    
    print &quot;$a $b&quot;; # 10 20

    my $c = new ReferenceObject: value =&gt; 10;
    my $d = $c;

    $c.set_value(20)

    print &quot;$c $d&quot;; # 20 20</pre>
<a name='Just when you thought you understood value types...'></a><h2>Just when you thought you understood value types...</h2>
<p>Along come compound value types to mess with your head. Assuming a
strict interpretation of value type declarations (assigning the the
'wrong' type to a variable throws an error), consider the following:</p>
<pre>    my @a of Int = (1, 2, 3);
    my @b = @a;
    my @c of Str;</pre>
<p>What happens to each of the following? If it's an error does it happen
at runtime or compile time?</p>
<pre>    @c = @a;
    @c = @b;

    push @a, &quot;String&quot;;
    push @b, &quot;String&quot;;</pre>
<p>Are you sure about those? Now, what happens if you start with:</p>
<pre>    my @a of Int = (1 .. Inf);
    my @b = @a;
    my @c of Str;</pre>
<p>And there's more thorny problems where they came from.</p>
<a name='Those thread links'></a><h2>Those thread links</h2>
<p><a href='http://groups.google.com/groups?threadm=200304140058.h3E0wlpa001034@bruce.csse.monash.edu.au' target='_blank'>groups.google.com</a> -- Types of
literals</p>
<p><a href='http://groups.google.com/groups?threadm=20030411204244.GG561@wall.org' target='_blank'>groups.google.com</a> -- Do we really need the
dual type system</p>
<p><a href='http://groups.google.com/groups?threadm=200304142143.11432.afaus@corp.vlex.com' target='_blank'>groups.google.com</a> -- User defined hierarchical
types</p>
<p><a href='http://groups.google.com/groups?threadm=a05210606bac48f32d796@' target='_blank'>groups.google.com</a>[63.120.19.221] -- Mind the difference
between value types and reference types</p>
<p><a href='http://groups.google.com/groups?threadm=ygcof343oc6.fsf@babylonia.flatirons.org' target='_blank'>groups.google.com</a> -- Static typing with
Interfaces</p>
<p><a href='http://groups.google.com/groups?threadm=001D81EE-71D1-11D7-BA15-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a> -- Michael
Lazzaro's superb summary of how containers and values interact. Not
sure it's the whole story though...</p>
<a name='Acknowledgements, Announcements and Apologies'></a><h1>Acknowledgements, Announcements and Apologies</h1>
<p>Sorry it's late. I blame the perl6-language people. It has nothing
whatsoever to do with weekend spent in Wales and a Bank Holiday Monday
spent at an Easter egg hunt and barbecue at my aunt's.</p>
<p>This has been one of the harder Perl 6 summaries to write, mostly
because the language list has been dealing with a complicated subject
and finding lots of interesting corners and ambiguities. Many thanks
to Michael Lazzaro for his careful summation of his understanding of
how things work which certainly clarified my thinking, to
St&eacute;phane Payrard for his sanity check of the types summary and
to Dan Sugalski for a few answers on IRC about Scalar behaviour.</p>
<p>If you've appreciated this summary, please consider one or more of the
following options:</p>
<ul>
<li><a name='Send money to the Perl Foundation at donate.perl-foundation.org/ and help support the ongoing development of Perl.'></a>Send money to the Perl Foundation at
<a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> and help support the ongoing
development of Perl.</li>
<li><a name='Get involved in the Perl 6 process. The mailing lists are open to all. dev.perl.org/perl6/ and www.parrotcode.org/ are good starting points with links to the appropriate mailing lists.'></a>Get involved in the Perl 6 process. The mailing lists are open  to
all. <a href='http://dev.perl.org/perl6/' target='_blank'>dev.perl.org</a> and <a href='http://www.parrotcode.org/' target='_blank'>www.parrotcode.org</a>
are good starting points with links to the appropriate mailing lists.</li>
<li><a name='Send feedback, flames, money, photographic and writing commissions, or a full set of Bertrand Harris Bronson's The Traditional Tunes of the Child Ballads to p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a>'></a>Send feedback, flames, money, photographic and writing commissions, or
a full set of Bertrand Harris Bronson's <i>The Traditional Tunes of the
Child Ballads</i> to <i><a href='http://search.cpan.org/perldoc?<a href='mailto:p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a>'>p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a></a></i></li>
</ul>
</div>
